암호화 키 파기 (Cryptographic Key Destruction)
1. 개요
암호화 키 파기란 더 이상 사용되지 않거나 유효 기간이 만료된 암호화 키를 복구 불가능한 상태로 완전히 제거하여, 해당 키를 이용한 데이터 복호화 가능성을 원천적으로 차단하는 보안 프로세스를 의미한다.
암호화 키는 생성, 저장, 배포, 사용, 갱신, 보관, 파기의 [암호화 키 생명주기]를 거치며, 파기는 이 생명주기의 최종 단계이다. 적절한 파기 절차가 수행되지 않은 키는 공격자에게 유출될 경우 과거에 저장된 암호화 데이터(Ciphertext)가 모두 노출되는 치명적인 보안 사고로 이어질 수 있다.
2. 키 파기의 목적 및 중요성
키 파기의 핵심 목적은 키의 생명주기가 종료된 시점에서 해당 키에 대한 모든 접근 권한을 영구적으로 제거하는 것이다. 이때 키 만료(Expiration)와 키 파기(Destruction)를 구분해야 한다. 만료는 해당 키를 더 이상 새로운 암호화에 사용하지 않는 상태(Read-only)를 의미하며, 파기는 키 자체를 복구 불가능하게 제거하여 복호화조차 불가능하게 만드는 상태를 의미한다.
- 데이터 복구 가능성 차단: 키가 유출되더라도 파기된 키를 이용한 복호화가 불가능하게 함으로써 데이터의 기밀성을 유지한다.
- 컴플라이언스 준수:
- GDPR (EU 일반 데이터 보호 규칙): 사용자의 '잊힐 권리(Right to be Forgotten)'를 구현하기 위해, 특정 사용자의 데이터를 암호화한 키를 파기함으로써 데이터를 논리적으로 완전히 삭제한 것으로 간주하는 기법이 활용된다.
- ISMS-P (정보보호 및 개인정보보호 관리체계 인증): 암호 키의 생성부터 파기까지의 전 과정을 관리하고 기록하도록 규정하고 있다.
- 공격 표면(Attack Surface) 감소: 불필요하게 보관 중인 키의 수를 줄여 관리 포인트를 최소화하고 잠재적인 유출 경로를 차단한다.
3. 키 파기 방법론
저장 매체의 특성과 키 관리 방식에 따라 파기 기법이 달라진다.
| 구분 |
논리적 삭제 (Logical Deletion) |
물리적 파기 (Physical Destruction) |
암호학적 파기 (Crypto-shredding) |
| 정의 |
파일 시스템 상의 포인터 제거 또는 데이터 덮어쓰기(Overwriting) |
키가 저장된 하드웨어 매체를 물리적으로 파괴하는 방식 |
데이터를 암호화한 키(DEK)를 다시 암호화한 마스터 키(KEK)를 파기하는 방식 |
| 특징 |
단순 삭제는 복구 가능하나, 제로필(Zero-fill)이나 와이핑(Wiping) 적용 시 신뢰도 상승 |
가장 확실한 파기 방법이나 매체 재사용 불가 |
대규모 클라우드 환경 및 가상화 환경에 최적화 |
| 적용 대상 |
일반 파일 시스템, 임시 키 |
[[HSM]], TPM, 전용 저장 장치 |
[[KMS]], 클라우드 스토리지, DB 암호화 데이터 |
| 신뢰 수준 |
낮음 $\rightarrow$ 보통 (기법에 따라 차이) |
매우 높음 |
높음 |
[참고] 암호학적 파기(Crypto-shredding) 구조도
암호학적 파기는 계층적 키 구조를 이용하여 하위 키를 직접 삭제하는 대신 상위 키를 파기함으로써 하위 데이터를 무효화한다.
평문 데이터 $\xrightarrow{DEK로 암호화}$ 암호문 $\xrightarrow{KEK로 암호화}$ 암호화된 DEK (Wrapped DEK)
$\Rightarrow$ [KEK 파기] $\Rightarrow$ 암호화된 DEK 복구 불가 $\Rightarrow$ 평문 데이터 복구 불가 (파기 완료)
4. 환경별 파기 구현 전략
4.1 온프레미스(On-premises) 환경
물리적 제어가 가능한 환경에서는 하드웨어 기반의 보안 모듈을 주로 사용한다.
* [[HSM]] (Hardware Security Module): 하드웨어 보안 모듈 내의 키를 삭제하며, 물리적 탬퍼링(Tampering) 감지 시 키를 자동 파기하는 기능을 활용한다.
* TPM (Trusted Platform Module): 메인보드에 내장된 보안 칩의 키를 초기화(Clear)하여 하드웨어 수준에서 파기한다.
4.2 클라우드(Cloud) 환경
클라우드에서는 API 기반의 [KMS]를 통해 키를 관리하며, 즉시 삭제보다는 '삭제 예약' 기간을 두는 것이 일반적이다.
* KMS (Key Management Service): AWS KMS, Azure Key Vault, Google Cloud KMS 등을 통해 키 상태를 Pending Deletion으로 변경한다.
* Vault (HashiCorp): 키 버전 관리 및 삭제 API를 통해 논리적 파기를 수행한다.
[코드 예시 1: AWS CLI를 이용한 KMS 키 삭제 예약]
# KMS 키를 30일 후 삭제하도록 예약 (최소 7일 ~ 최대 30일 설정 가능)
aws kms schedule-key-deletion \
--key-id <Key-ID-or-ARN> \
--pending-window-in-days 30
[코드 예시 2: HashiCorp Vault API를 이용한 키 삭제]
# Vault의 Transit 엔진에서 특정 키를 삭제
curl --header "X-Vault-Token: <TOKEN>" \
--request DELETE \
<VAULT_ADDR>/v1/transit/keys/<KEY_NAME>
5. 파기 절차 및 검증
5.1 키 파기 전 체크리스트
키 파기는 되돌릴 수 없는 작업이므로 실행 전 반드시 다음 사항을 확인해야 한다.
- [ ] 데이터 의존성 확인: 해당 키로 암호화된 데이터 중 여전히 복호화가 필요한 데이터가 남아있는가?
- [ ] 백업 확인: 법적 보관 주기나 비즈니스 요구사항에 따라 키 백업본이 안전하게 보관되었는가?
- [ ] 영향도 분석: 키 파기 시 서비스 중단이나 애플리케이션 오류가 발생하는 지점이 있는가?
- [ ] 승인 절차: 보안 책임자 및 데이터 소유자의 최종 승인을 득하였는가?
5.2 표준 파기 프로세스
- 파기 요청: 키 관리자가 파기 대상 키와 사유를 명시하여 요청한다.
- 승인: 다중 승인 체계(M-of-N)를 통해 권한 있는 관리자들이 승인한다.
- 파기 실행: 선택한 방법론(물리적/논리적/암호학적)에 따라 키를 제거한다.
- 로그 기록: 파기 일시, 파기자, 승인자, 파기 방법, 대상 키 ID를 감사 로그(Audit Log)에 기록한다.
- 확인서 발행: 파기 완료 보고서 또는 확인서를 발행하여 거버넌스 증적으로 보관한다.
5.3 파기 후 데이터 접근 불가 테스트 사례
파기가 정상적으로 이루어졌는지 검증하기 위해 다음과 같은 테스트를 수행한다.
* 시나리오: 파기된 키 ID를 사용하여 기존 암호화된 데이터의 복호화를 시도한다.
* 기대 결과:
* KMS API 호출 시 InvalidKeyException 또는 KeyNotFound 에러가 발생하며 요청이 거부되어야 함.
* 복호화 함수 호출 시 Decryption Failed 또는 Null 값이 반환되어 평문 데이터가 노출되지 않아야 함.
* 보안 로그(Audit Log)에 해당 파기된 키를 이용한 접근 시도 실패 기록이 정확히 남아야 함.
6. 주의사항 및 위험 요소
- 데이터 손실(Data Loss): 키를 파기하는 순간 해당 키로 암호화된 모든 데이터는 복구 불가능한 데이터(Irrecoverable Data)가 된다. 이는 의도치 않은 데이터 손실로 이어질 수 있으므로 주의가 필요하다.
- 백업본 관리: 운영 환경의 키를 파기했더라도 오프라인 백업이나 재해 복구(DR) 센터에 키 복사본이 남아있다면 완전한 파기로 볼 수 없다. 모든 복제본의 동시 파기가 필요하다.
- 보관 주기 설정: 법적 규제(예: 전자금융거래법 등)에 따라 일정 기간 키를 보관해야 하는 경우가 있으므로, 무조건적인 즉시 파기보다는 보관 주기(Retention Period)를 설정한 후 파기해야 한다.
7. 관련 가이드라인 및 참조
더 자세한 표준 및 기술 지침은 아래의 공식 가이드라인을 참조하시기 바랍니다.
* NIST SP 800-57: Recommendation for Key Management
* NIST SP 800-88: Guidelines for Media Sanitization
* KISA 암호 알고리즘 및 키 관리 가이드라인
* [ISO/IEC 11770: Information technology — Security techniques — Key management]
# 암호화 키 파기 (Cryptographic Key Destruction)
## 1. 개요
**암호화 키 파기**란 더 이상 사용되지 않거나 유효 기간이 만료된 암호화 키를 복구 불가능한 상태로 완전히 제거하여, 해당 키를 이용한 데이터 복호화 가능성을 원천적으로 차단하는 보안 프로세스를 의미한다.
암호화 키는 생성, 저장, 배포, 사용, 갱신, 보관, 파기의 [[암호화 키 생명주기]](Key Lifecycle)를 거치며, 파기는 이 생명주기의 최종 단계이다. 적절한 파기 절차가 수행되지 않은 키는 공격자에게 유출될 경우 과거에 저장된 암호화 데이터(Ciphertext)가 모두 노출되는 치명적인 보안 사고로 이어질 수 있다.
## 2. 키 파기의 목적 및 중요성
키 파기의 핵심 목적은 키의 생명주기가 종료된 시점에서 해당 키에 대한 모든 접근 권한을 영구적으로 제거하는 것이다. 이때 **키 만료(Expiration)**와 **키 파기(Destruction)**를 구분해야 한다. 만료는 해당 키를 더 이상 새로운 암호화에 사용하지 않는 상태(Read-only)를 의미하며, 파기는 키 자체를 복구 불가능하게 제거하여 복호화조차 불가능하게 만드는 상태를 의미한다.
* **데이터 복구 가능성 차단:** 키가 유출되더라도 파기된 키를 이용한 복호화가 불가능하게 함으로써 데이터의 기밀성을 유지한다.
* **컴플라이언스 준수:**
* **GDPR (EU 일반 데이터 보호 규칙):** 사용자의 '잊힐 권리(Right to be Forgotten)'를 구현하기 위해, 특정 사용자의 데이터를 암호화한 키를 파기함으로써 데이터를 논리적으로 완전히 삭제한 것으로 간주하는 기법이 활용된다.
* **ISMS-P (정보보호 및 개인정보보호 관리체계 인증):** 암호 키의 생성부터 파기까지의 전 과정을 관리하고 기록하도록 규정하고 있다.
* **공격 표면(Attack Surface) 감소:** 불필요하게 보관 중인 키의 수를 줄여 관리 포인트를 최소화하고 잠재적인 유출 경로를 차단한다.
## 3. 키 파기 방법론
저장 매체의 특성과 키 관리 방식에 따라 파기 기법이 달라진다.
| 구분 | 논리적 삭제 (Logical Deletion) | 물리적 파기 (Physical Destruction) | 암호학적 파기 (Crypto-shredding) |
| :--- | :--- | :--- | :--- |
| **정의** | 파일 시스템 상의 포인터 제거 또는 데이터 덮어쓰기(Overwriting) | 키가 저장된 하드웨어 매체를 물리적으로 파괴하는 방식 | 데이터를 암호화한 키(DEK)를 다시 암호화한 마스터 키(KEK)를 파기하는 방식 |
| **특징** | 단순 삭제는 복구 가능하나, 제로필(Zero-fill)이나 와이핑(Wiping) 적용 시 신뢰도 상승 | 가장 확실한 파기 방법이나 매체 재사용 불가 | 대규모 클라우드 환경 및 가상화 환경에 최적화 |
| **적용 대상** | 일반 파일 시스템, 임시 키 | [[HSM]], TPM, 전용 저장 장치 | [[KMS]], 클라우드 스토리지, DB 암호화 데이터 |
| **신뢰 수준** | 낮음 $\rightarrow$ 보통 (기법에 따라 차이) | 매우 높음 | 높음 |
### [참고] 암호학적 파기(Crypto-shredding) 구조도
암호학적 파기는 계층적 키 구조를 이용하여 하위 키를 직접 삭제하는 대신 상위 키를 파기함으로써 하위 데이터를 무효화한다.
`평문 데이터` $\xrightarrow{DEK로 암호화}$ `암호문` $\xrightarrow{KEK로 암호화}$ `암호화된 DEK (Wrapped DEK)`
$\Rightarrow$ **[KEK 파기]** $\Rightarrow$ `암호화된 DEK` 복구 불가 $\Rightarrow$ `평문 데이터` 복구 불가 (파기 완료)
## 4. 환경별 파기 구현 전략
### 4.1 온프레미스(On-premises) 환경
물리적 제어가 가능한 환경에서는 하드웨어 기반의 보안 모듈을 주로 사용한다.
* **[[HSM]] (Hardware Security Module):** 하드웨어 보안 모듈 내의 키를 삭제하며, 물리적 탬퍼링(Tampering) 감지 시 키를 자동 파기하는 기능을 활용한다.
* **TPM (Trusted Platform Module):** 메인보드에 내장된 보안 칩의 키를 초기화(Clear)하여 하드웨어 수준에서 파기한다.
### 4.2 클라우드(Cloud) 환경
클라우드에서는 API 기반의 [[KMS]](Key Management Service)를 통해 키를 관리하며, 즉시 삭제보다는 '삭제 예약' 기간을 두는 것이 일반적이다.
* **KMS (Key Management Service):** AWS KMS, Azure Key Vault, Google Cloud KMS 등을 통해 키 상태를 `Pending Deletion`으로 변경한다.
* **Vault (HashiCorp):** 키 버전 관리 및 삭제 API를 통해 논리적 파기를 수행한다.
**[코드 예시 1: AWS CLI를 이용한 KMS 키 삭제 예약]**
```bash
# KMS 키를 30일 후 삭제하도록 예약 (최소 7일 ~ 최대 30일 설정 가능)
aws kms schedule-key-deletion \
--key-id <Key-ID-or-ARN> \
--pending-window-in-days 30
```
**[코드 예시 2: HashiCorp Vault API를 이용한 키 삭제]**
```bash
# Vault의 Transit 엔진에서 특정 키를 삭제
curl --header "X-Vault-Token: <TOKEN>" \
--request DELETE \
<VAULT_ADDR>/v1/transit/keys/<KEY_NAME>
```
## 5. 파기 절차 및 검증
### 5.1 키 파기 전 체크리스트
키 파기는 되돌릴 수 없는 작업이므로 실행 전 반드시 다음 사항을 확인해야 한다.
- [ ] **데이터 의존성 확인:** 해당 키로 암호화된 데이터 중 여전히 복호화가 필요한 데이터가 남아있는가?
- [ ] **백업 확인:** 법적 보관 주기나 비즈니스 요구사항에 따라 키 백업본이 안전하게 보관되었는가?
- [ ] **영향도 분석:** 키 파기 시 서비스 중단이나 애플리케이션 오류가 발생하는 지점이 있는가?
- [ ] **승인 절차:** 보안 책임자 및 데이터 소유자의 최종 승인을 득하였는가?
### 5.2 표준 파기 프로세스
1. **파기 요청:** 키 관리자가 파기 대상 키와 사유를 명시하여 요청한다.
2. **승인:** 다중 승인 체계(M-of-N)를 통해 권한 있는 관리자들이 승인한다.
3. **파기 실행:** 선택한 방법론(물리적/논리적/암호학적)에 따라 키를 제거한다.
4. **로그 기록:** 파기 일시, 파기자, 승인자, 파기 방법, 대상 키 ID를 감사 로그(Audit Log)에 기록한다.
5. **확인서 발행:** 파기 완료 보고서 또는 확인서를 발행하여 거버넌스 증적으로 보관한다.
### 5.3 파기 후 데이터 접근 불가 테스트 사례
파기가 정상적으로 이루어졌는지 검증하기 위해 다음과 같은 테스트를 수행한다.
* **시나리오:** 파기된 키 ID를 사용하여 기존 암호화된 데이터의 복호화를 시도한다.
* **기대 결과:**
* KMS API 호출 시 `InvalidKeyException` 또는 `KeyNotFound` 에러가 발생하며 요청이 거부되어야 함.
* 복호화 함수 호출 시 `Decryption Failed` 또는 `Null` 값이 반환되어 평문 데이터가 노출되지 않아야 함.
* 보안 로그(Audit Log)에 해당 파기된 키를 이용한 접근 시도 실패 기록이 정확히 남아야 함.
## 6. 주의사항 및 위험 요소
* **데이터 손실(Data Loss):** 키를 파기하는 순간 해당 키로 암호화된 모든 데이터는 **복구 불가능한 데이터(Irrecoverable Data)**가 된다. 이는 의도치 않은 데이터 손실로 이어질 수 있으므로 주의가 필요하다.
* **백업본 관리:** 운영 환경의 키를 파기했더라도 오프라인 백업이나 재해 복구(DR) 센터에 키 복사본이 남아있다면 완전한 파기로 볼 수 없다. 모든 복제본의 동시 파기가 필요하다.
* **보관 주기 설정:** 법적 규제(예: 전자금융거래법 등)에 따라 일정 기간 키를 보관해야 하는 경우가 있으므로, 무조건적인 즉시 파기보다는 보관 주기(Retention Period)를 설정한 후 파기해야 한다.
## 7. 관련 가이드라인 및 참조
더 자세한 표준 및 기술 지침은 아래의 공식 가이드라인을 참조하시기 바랍니다.
* [NIST SP 800-57: Recommendation for Key Management](https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final)
* [NIST SP 800-88: Guidelines for Media Sanitization](https://csrc.nist.gov/publications/detail/sp/800-88/final)
* [KISA 암호 알고리즘 및 키 관리 가이드라인](https://www.kisa.or.kr)
* [ISO/IEC 11770: Information technology — Security techniques — Key management]